MultiModule help

skretchmer wrote: Just to be complete, I did go back and remove all modules except the chip itself, commented everything out of the hardware.ini file but the MM line, and it did repeat the "bad" behavior of showing module missing (as well as making the CYRF module show as missing with the board and chip installed, but everything commented out of the hardware.ini file). Then once re-inserting all 3 modules in the board, and re-enabling them in the hardware.ini file, it works fine again. So either I was creating, and conveniently removing some wiring glitch with those operations, or there is something now that prevents the MM from working with no modules.

Why would you enable the MM if there are no RF modules attached to it? That serves absolutely no purpose. The ATtiny micro-controller is basically just a programmable switch that supplies power to, and routes Tx data to, a single RF module. A MM not populated with at least one RF module, along with a properly edited hardware.ini file, will not have any modules that can be detected, .....thus, the missing module.

As far as the CYRF module goes, the one that is referred to in the hardware.ini file is supposed to be an additional CYRF6936 that is attached to the MM, not the CYRF that is on the main board of the Tx. So, if you enabled the MM and uncommented the CYRF lines in the hardware.ini file, there would not be a CYRF module to detect on the MM, again......missing module.

skretchmer wrote: One thing you might want to add to the wiki on the module build is to specify that all the "local" connections for the modules need to be done even when installing in a MM board. I mean the 5-9 and 7-10 shorting of the GDO pins to the PA and LNA pins on some of the modules. I realized I had been assuming that was done by the board, and I think not adding those jumpers to the modules was part of my problems. (along with the CE pin getting to VCC)

I will definitely let you know once I can confirm the CC2500 is functional, but i'm not sure I will be able to tell if it's working at full power or not.

thanks

According to the Wiki deviation / ModuleList, the Multi-Module is not supported by Deviation firmware v4.0.1(the current version), or earlier versions, and it is stated so in the Multi-Module portion at the bottom of the Wiki page:

*************************************************
MultiModule

The MultiModule is a circuit-board + ATTiny AVR chip which can be used to control up to 4 modules on a Deviation Transmitter.

The MultiModule is only supported by the nightly-builds at the moment, and will not work with Deviation 4.0.1 or earlier.

If installing a 'DEVO' CYRF6936 module into the MultiMod, the 5.0V pin must be connected between the MultiMod and the Transmitter, otherwise it can be left floating

The Reset pin only needs to be connected if you plan to program the AVR via your transmitter. In this case, connect the 'Reset' pin to the 'TCK' pin of the Devo transmitter
*************************************************

I am not positive if this is still the case, or if v4.0.1 has been updated to support the MM after the Wiki was written or edited. I can't remember if you tried the Nightly Builds or not, ....something to consider. I know for a fact that the MM v1.3 traces (and I suspect the v1.2 does as well) for sure jumps the necessary pins/pads of the CC2500 and A7105 RF modules that are listed in the Wiki for use with the Newer than v4.0.1(Nightly Builds) versions of the Deviation firmware, otherwise, my MM would not be working, because I did no such "local" jumping of pads on each RF module. You can check these pin jumps on a blank MM with a multi-meter continuity test per the following picture >>>

They match the pin/pad jumps for the Skyartec & CC2500(5->10 & 7->9), and also the XL2500(3->10 and 8->9) modules that have PA & LNA, and also match the pin/pad jumps for the A7105(6->9 and 7->8)that has PA & LNA.

The CE(chip enable) of the nRF24L01 +PA +LNA should not need to be jumped to the 3.3v pin, as the ATtiny switches that on when used with the MM. It should only need to be jumped when using it without a MM.

I'm not sure why you have had so much trouble, you seem to be an anomaly for some reason, but there have been successful MM builds with a DEVO 7e before, although there have been some recent text revisions (and a colored dot location error on one of the pictures) to the Wiki to clarify the v4.0.1 and earlier versions vs, the newer than v4.0.1 (A.K.A. the Nightly Builds until there is a new release of Deviation) versions. You seem to have somehow succeeded with your method finally, so that is a good thing, but I don't think that the Wiki needs to be changed if others are building working MM's as it currently is.

RedSleds wrote: Why would you enable the MM if there are no RF modules attached to it? That serves absolutely no purpose.

Because I suggested it. I did that because it worked properly for me when I last mucked with the MM a while back.

And it serves the same purpose as trying the MM with only one or two modules in it. While there's no rational reason to use any of those configurations, since you don't need the MM for them, they are all interesting cases for testing.

The system can detect a missing MM, so it should - if everything were working rationally - report it as missing only if it actually failed to talk to the ATTiny to tell it which module it wanted to talk to.

Looking at the current code, it looks like it won't find the MM unless there's a module plugged into it, because it depends on the tests for at least one of those modules to initialize the MM as a side effect. And yup, this is a change from older behavior.

I'd argue this is a bug, but don't feel strongly enough about it to figure out the code changes required to fix it.

If you read through the entire thread you would see that I am using the most recent nightly build. I started with the one posted late June, but then during my "project" the july NB went up, and I moved to that build, which is the one I am running now.

As mwm has said, I was only trying the MM board without any modules as a troubleshooting step, as this was suggested earlier in the thread as a good way to find out if the MM board was working at all.

I believe the majority of the trouble I had was with the programming of the ATTiny chip. I was never able to get a successful programming sequence to occur while trying to use the 7e as the programmer. Once the USBASP programmer from Banggood arrived, I was able to successfully program the chip. Unfortunately I was already trying the MM board with no modules as my basic test for functionality. The first time it occurred to me to test the MM board with all modules installed AFTER getting the ATTiny programmed with the USB programmer, it was recognized. (except for the NRF chip.) I was then able to uncomment out all the modules except the NRF AND the secondary CYRF chip (which I was NEVER trying to enable during my "project".) and have it work fine. Then once I put a jumper on the CE pin to the VCC pin on the NRF, I was able to get all three modules to function on the MM board.

I am going to go back and verify the CE-VCC pin needed to be connected separately from the MM, just to see if it's truly a necessary step now, or if I just missed something at the end of a long and frustrating "project".

I would not think that any changes would be necessary to make the MM-board-only test valid, as I have said, it was only being done as a troubleshooting step.

thanks

Ok now, FWIW, I have verified that my working MM, with all three modules, (7105, NRF, and CC2500) will not bind to anything using the NRF chip without the CE pin shorted to VCC separately from the MM board. I am testing bind to a V977 that binds instantly on power-up when the CE pin is shorted, and will not bind at all to the same TX, same model file, without the pin shorted. This was the behavior I saw with my test build, and with my currently-in-use full MM build from scratch. (new modules and a new board once I got my test build working and got past my programming issues)

As soon as I short the pin to VCC it binds, I do not even need to re-power the TX or the bird. Video to be added shortly showing this.

in this video you can see the TX bind with the CE pin shorted to VCC, and lose the bind as soon as the short is removed.

Strange indeed! But, as long as everything is functioning now with the 2->3 pin jump on the nRF module, I guess you kind of have to go with that and see how it all works out when flying your models.

You certainly have had a time of it with this 7e, and I admire your tenacity!

Happy flying!

I am curious if this means my NRF module is always active, whereas the others, and a "correctly" functioning setup would be turned off unless actually being used?

Only the NRF has a CE pin, does that mean all the others are always on anyway, only the NRF could be turned off at all.

My desire all along was to have a 7e with MM. I was willing to take a shot that it was the 7e that was the issue, and got a 10 to try with. I had a Taranis + I was using before, I just got tired of having to swap modules in the back every time i wanted to fly a different protocol. Anything without that hassle would have been good for me, but i definately prefer the smaller size of the 7e, and I don't need the extra controls.

Now that I have a working 7e I will just stick with that. I only ordered 3 v1.3 boards originally, and i did break one during my trial runs. One is what became my experimental board with sockets installed, making it much to big to fit inside, and the last became the working MM I have now. I do have a bunch of modules left, so I ordered another set of 3 boards from OSHpark, and plan on doing a build for the 10 when they arrive. After that I might try and sell it, or keep it around as a back up radio, although I don't like changing form factors like that when flying.

My next "fun time with programming" is a pair of Blade mCPX BL helis with programmable speed controllers. After my experience with programming the MM i'm a bit leary about how this will go, but I will just start with a real USB programmer from the beginning and hope for the best.

thanks

I thought that I remembered something about you also got a DEVO 10! ....wasn't sure though and couldn't find anything about it in this thread.

Hopefully, the MM build for the 10 will go much smoother than your 7e build!

Mine pretty much went by the numbers. I relied heavily on SeBy_DocKy's video tutorial for guidance and had it working the first attempt. I did have some minor troubles with some of the assembly of it though. If you have not seen my blog page over on RCGroups about my build, it could give you some idea about my troubles, and alternate ideas I had that made the MM fitment into the Tx case a little less cramped for space. >>> My DEVO 10 Multi-Module Build <<<

skretchmer wrote: I am curious if this means my NRF module is always active, whereas the others, and a "correctly" functioning setup would be turned off unless actually being used?

Only the NRF has a CE pin, does that mean all the others are always on anyway, only the NRF could be turned off at all.

........

I am pretty sure that your nRF module would not be powered up unless it is the one you have selected to be active with the Tx GUI, as the ATtiny should only supply 3.3v to one RF module at a time, so the CE pin of the nRF won't be getting any power from the 3.3v pin if it isn't getting any.

EDIT: Evidently the above comment is all wrong, because the 3.3v & GRD of the v1.3 MM's P1 pad traces go to each of the RF modules corresponding 3.3v & GRD pads without passing through the ATtiny. My bad!

the ATtiny chip only switches the CSN pin. The 3.3V pin is shorted to each module on the MM. I get continuity between the MM's 3.3v pin and every module VCC pin even with no modules or the ATTiny chip installed.

So it looks like all modules are powered all the time. I assumed the PA_ and LNA_ pin shortings were the control mechanism for powering the modules in the case of the 7105 and 2500, and that the CE pin was the enable signal for the NRF.

Oh wow! You're right, I never did check for that.

I only ever checked that the GND was common from the Tx to the MM's P1 block, and to each GND pin location for all my RF modules, and just assumed that the 3.3v power to each was switched through the ATtiny. Oops!

Could someone help me find the avr.hex file for my devo 10 so I can finish the multimodule? The link seby docky provided isn't good anymore. Thanks

www.deviationtx.com/downloads-new/category/7-programmer-dfus#

I've hit a roadblock. After flashing the 1.2 board with attiny chip, i keep getting the ERR: no switch cfg message. I know that means my hardware.ini. isn't up to par. I've changed all the parameters listed in this thread but I still get the message. My attiny is soldered in the correct orientation and the dfu uploaded just fine. Here is my hardware.ini layout. Please advise on how to fix this.
;Only useful for transmitters with an after-market vibration motor
;enable-haptic=1
;
;switch_types: 3x2, 3x1, 2x2
;extra-switches=
;
;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 = S1
; has_pa-a7105 = 1
; enable-cc2500 = S3
; has_pa-cc2500 = 1
; enable-nrf24l01 = S402
; has_pa-nrf24l01 = 1
; enable-multimod = A13
; enable-switch = A13

Assuming that you have added all three nRF24L01, A7105, and CC2500 transceivers, your hardware ini should look like this:

;Only useful for transmitters with an after-market vibration motor
;enable-haptic=1
;
;switch_types: 3x2, 3x1, 2x2
;extra-switches=
;
[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 = S1
has_pa-a7105 = 1
enable-cc2500 = S3
has_pa-cc2500 = 1
enable-nrf24l01 = S402
has_pa-nrf24l01 = 1
enable-multimod = A13

Although, if any of your modules do not have power amplifier circuitry included on them, those "has_pa" corresponding lines should remain commented out with the semicolon left at the front of the line. (same goes for any module that is not installed on your MM)

Thanks Red Sleds. I had multi module uncommented. So I commented it and now I have gotten past the ERR: no switch cfg message but I am getting a Err: no switch found error screen. I don't have any modules installed yet because I'm not sure my attiny is properly formatted yet. I still havent received the verification screen. Any advise?

If you got the DEVO 10 screen after you flashed the ATTiny 24A, as follows:

****************
Found AVR: 0b911e53
hex: 338bytes
6 verified
****************


I think you are just jumping the gun here.

Populate the board with transceivers, edit the hardware.ini as needed, ...then try it all out.

Just a question about the multiModule.
What's the reason for the advice to trim the pins of components when instilling on the board? Why do it?

Space. The MM is a tight fit even in a full size transmitter. Trimming the pins shrinks it a little and makes it easier to insulate them to prevent shorts.

Hi can anyone please confirm that he managed to flash his attiny 24a from devo 7e?
using:

Programmer dfu for devo 7e:
www.deviationtx.com/downloads-new/catego...95:programmer-devo7e

hex file v3 avr.hex:
www.deviationtx.com/downloads-new/catego...ownload=6:multimodv3

I have put the hex file in a blank drive but no result....