Developing a universal module

More
16 Jan 2014 14:18 #18565 by MassiveOverkill
Replied by MassiveOverkill on topic Developing a universal module
Hey guys. I've put selling our modded Devos on hold until this comes to fruition. I've been really maintaining the shop but if there's anything you need from me\James to help this project, please let me know. I haven't been able to follow all the technical stuff but am lurking nonetheless. Thanks for all the hard work.

Please Log in or Create an account to join the conversation.

More
16 Jan 2014 17:10 #18569 by victzh
Replied by victzh on topic Developing a universal module
Can you handle switch from Tx to Rx on the level of RF chip driver, and use high level function in protocols? This way it would be only 4 places to take care of, not potentially dozens of protocols.

Please Log in or Create an account to join the conversation.

More
16 Jan 2014 19:02 #18570 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
What I've done is to add functions:
A7105_SetTxRxMode(mode)
CC2500_SetTxRxMode(mode)
CYRF_SetTxRxMode(mode)
(That last one already exists, but I renamed it to be consistent)
There are 3 legal modes:
TX_EN: setup PA for transmitting (and disable LNA if needed)
RX_EN: setup LNA for transmitting (and disable PA if needed)
TXRX_OFF: enter sleep mode with PA/LNA off

Now we just need to plumb them into the protocols. The cyrf protocols are already done. I did the hubsan protocol and verified it works, flysky never enters Rx mode, so that one is easy. I'll deal with the CC2500 protocols next. None of the nrf24L01 modules have a controllable PA/LNA so this is not needed there.
However, in the next revision of the board, the nrf24l01 CE pin will be programmable via the AVR chip. So we could add a Tx/Rx mode function that uses is if available. I looked through the 24L01 protocols and none of them seem to enter read mode today, so apparently it isn't needed right now?

I found I can't run the SPI any faster than 560kHz (72/128). I can theoretically run at 1.2MHz (72/64) but I need to add delay between sending bytes in that case. The AVR takes ~70us to actually setup everything after the SPI transfer which means that the time to switch a pin on the AVR is currently ~150us. I can reduce that significantly by doing the logic in the STM32 instead (basically having the STM32 compute 'set portA to this value when CSN is high and this other value when CSN is low'), so I'm going to go that route. I'd like to get the timing as fast as possible to optimize the utility.

I'm trying to decide how general purpose to make this. I could add a full control interface to the tx.ini file (specify the CS, CE, Reset, etc for each module) or I could support one board layout (port0 is cyrf, port1 is a7105, ...). The 1st is definitely more flexible but adds quite a bit of code for limited benefit. Hardcoding the switch functionality is easier, but means we can't easily support other implementations. The switch code has already added ~600bytes of code (and it doesn't build on the Devo7e yet, and will likely require more). Adding configurability will likely double that.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 04:29 #18576 by victzh
Replied by victzh on topic Developing a universal module
nRF24L01 current protocols do not need Tx/Rx switching, but I know couple of protocols that could use it - UDI U816/U818 uses it, Crazyflie uses both Tx and Rx and have telemetry. So it make sense to write a dummy for it, even if hardware is not currently implemented.

Hardcoding vs. configurable - hard to tell. As long as it's modular enough and can be easily replaced with other logic, hardcoded is OK.

You probably moved the code for CS_HI/CS_LO from macros to this piece of code as well, didn't you?

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 05:47 #18579 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
Currently each module still has a 'CS_LO' and 'CS_HI', but now they are functions instead of macros. I did this with a static function instead of a global one, as I can keep the code in the mod files for the 7e that way.

I found a good middle ground for the configurability of the modules.

there is a single translation function:
int SPI_ProtoGetPinConfig(int module, int state);
which takes a module type (CYRF6936, A7105, ...) and a info command:
CSN_PINS
ENABLED_PINS,
DISABLED_PINS,
RESET_PINS,
...

and returns the mapping based on what was paased into the 'pin' variable.

So for instance, your tx.ini file may look like:
[modules]
enable-cyrf6936 = B12
has_pa-cyrf6936 = 1
enable-switch   = A13
enable-a7105    = S1
has_pa-a7105    = 1
enable-nrf24l01 = S0402
; has_pa-nrf24l01 = 1
enable-cc2500   = S3
has_pa-cc2500   = 1
This function can translate the 'S0402' to mean 'nrf24l02 module is connected to the programmable switch, Using Pin A.2 for the CSN, and Pin B.1 for the CE'

It provides flexibility to encode module parameters without needing a bunch of new ini-handling code.

of course, I'd never expect a regualr user to know what 'S0402' means any more than 'A13'. It is just something they C&P from the manual.

In case you are wondering:
the 'pin' variable is interpreted as a hex number, and treated as 4 4-bit values in this case (code for each module can define it differently). '4' means to use the 4th switch-position as CE (because of how the AVR is wired, the bits are 0=A0, 1=A1, 2=A2, 3=A3, 4=B1, 5=B2, 6=A7) and '2' means to use the 2nd switch position (A2) for CSN

I also rewrote the AVR SPI parser to let the master do all of the logic, and I can now reconfigure the switch in 90us. Maybe playing around with it we can do even better, but it really isn't too bad at the moment.

I still need to work on getting this to build on a 7e, and then I'll commit it.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 07:43 #18580 by SeByDocKy
Replied by SeByDocKy on topic Developing a universal module
Sorry to ask a stupid question for this thread. Is the main goal of this work to sell somewhere this "universal module" ?

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 13:57 #18582 by Pattaya01
Replied by Pattaya01 on topic Developing a universal module
Since you are usin ATtiny, is this relevant for you?

atmelcorporation.wordpress.com/2014/01/1...ttiny-software-hack/

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 15:05 #18583 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module

SeByDocKy wrote: Sorry to ask a stupid question for this thread. Is the main goal of this work to sell somewhere this "universal module" ?

The answer is probably not.
There are a few options:
1) someone else decides to run with this and sell completed modules (A fully populated board probably costs ~$30 in parts for all 3 modules. Cost would certainly be more due to assembly labor. (adding the cyrf module for the X9D would add $25 to the cost)
2) I may sell just the board (a couple bucks plus shipping) and you can buy all the parts from ebay and assemble yourself. Once the boards work, I'll likely have some more printed up from a chinese supplier, which would give me 30 boards for $12 + shipping. The point being the boards aren't expensive.
3) you can have the boards printed yourself (they currently cost $9 for 3 boards shipped anywhere in the world) and buy the rest of the stuff you need from ebay. Having boards printed is as easy as typing in your address, uploading the board file I provide, and paying via paypal.

The only thing you need to assemble the board is:
1 AVRTiny24A chip ~ $2
1 CC2500 + PA ~ $8
1 A7105 + PA ~ $12
1 NRF24L01 + PA ~ $6
+ shipping

and then a pencil soldering iron and a bit of wire (both of which you need regardless to attach the board to your Tx). There is no difficult soldering here. Assembly should be quite straight forward

Lastly, let me stress that I'm not done with the board design yet. I have a prototype working, and I have test boards being manufactured, but there are known issues with those even though I don't even have them yet)

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 15:12 - 17 Jan 2014 15:13 #18584 by SeByDocKy
Replied by SeByDocKy on topic Developing a universal module

PhracturedBlue wrote:

SeByDocKy wrote: Sorry to ask a stupid question for this thread. Is the main goal of this work to sell somewhere this "universal module" ?

The answer is probably not.
There are a few options:
1) someone else decides to run with this and sell completed modules (A fully populated board probably costs ~$30 in parts for all 3 modules. Cost would certainly be more due to assembly labor. (adding the cyrf module for the X9D would add $25 to the cost)
2) I may sell just the board (a couple bucks plus shipping) and you can buy all the parts from ebay and assemble yourself. Once the boards work, I'll likely have some more printed up from a chinese supplier, which would give me 30 boards for $12 + shipping. The point being the boards aren't expensive.
3) you can have the boards printed yourself (they currently cost $9 for 3 boards shipped anywhere in the world) and buy the rest of the stuff you need from ebay. Having boards printed is as easy as typing in your address, uploading the board file I provide, and paying via paypal.

The only thing you need to assemble the board is:
1 AVRTiny24A chip ~ $2
1 CC2500 + PA ~ $8
1 A7105 + PA ~ $12
1 NRF24L01 + PA ~ $6
+ shipping

and then a pencil soldering iron and a bit of wire (both of which you need regardless to attach the board to your Tx). There is no difficult soldering here. Assembly should be quite straight forward

Lastly, let me stress that I'm not done with the board design yet. I have a prototype working, and I have test boards being manufactured, but there are known issues with those even though I don't even have them yet)


Since I have already the 3 RF chips, for sure... I am more interested by option 2) and if I am more confident in my capacity for 3). In fact, if this module can be used any devo supported by deviationx and also the X9D, it's just "amazing" ... clap clap ...

Another stupid question... If the CYRF is also installed on this universal module, can the built-in CYRF module can be bypassed ? (avoiding difficult diode mod for example)
Last edit: 17 Jan 2014 15:13 by SeByDocKy.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 15:20 #18585 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module

SeByDocKy wrote: Another stupid question... If the CYRF is also installed on this universal module, can the built-in CYRF module can be bypassed ? (avoiding difficult diode mod for example)

Yes. The only concern is that I'm not sure the module will fit in a Devo7e with the cyrf attached. If the AWA24S works (I just got one) it is much smaller than the Walkera module and would probably be a better option for the Devo7e.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 20:15 #18600 by victzh
Replied by victzh on topic Developing a universal module
MassiveOverkill is planning to sell modded Devo 7E's, and probably modules ready to install, so yes, there are takers for this.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 21:14 #18602 by SadSack
Replied by SadSack on topic Developing a universal module
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.

Please Log in or Create an account to join the conversation.

More
17 Jan 2014 22:52 #18606 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
You do not need to remove the cyrf module. the switch will play nice with it installed.. Though it you move it to switch control, you could use the 2mm socket to connect to the switch board (except for the lack of 3.3V which you still need to wire)

I haven't tried yet, but my plan is to create a custom dfu to program the AVR. Then you don't need a programmer. It is a good note on the 5V programmers potentially damaging your transceivers. I've been programming mine with all modules installed and haven't had an issue, but there is no guarantee.

Please Log in or Create an account to join the conversation.

More
18 Jan 2014 18:20 #18641 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
FYI, I checked in the switch code. I no longer have any way check the old method, as I removed all of the modules in order to install the switch in my Tx, so I'd appreciate any info on whether the latest code still works with currently installed modules.

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 02:29 #18659 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
I have written a AVR programmer for the Devo now, and it seems to work well.
I have only tested it with my prototype module so far (which has already been fuse set at 8MHz). I think the code is slow enough to run at the default 1MHz, but it is untested. If it doesn't work, I'll need to write a bit-banging SPI driver, since I've already slowed down the SPI as far as it'll go (or maybe I'll play with the core frequency)

Anyhow, you install the custom dfu, copy avr.hex to your fs, and turn on the Tx. It includes the USB stack so you can change the hex file by holding ENT during power-on.

I still need to write the code to set the fuse bits. Since screwing up fuse bits can brick the AVR (at least for ISP), I waited till last for that.

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 04:54 - 19 Jan 2014 04:56 #18664 by vlad_vy
Replied by vlad_vy on topic Developing a universal module
Is it required/recommended to rewire current installed modules (TXEN, RXEN,...) , as it done at 'transceiver_module_2014-01-13.pdf', or it will work as is?
Last edit: 19 Jan 2014 04:56 by vlad_vy.

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 09:56 - 19 Jan 2014 14:14 #18670 by vlad_vy
Replied by vlad_vy on topic Developing a universal module
At least all works fine with original wiring (as it is at 'ModuleInstallation.pdf'). With rewired XL7105-D03 module (GIO1->TXEN, GIO2->RXEN) Hubsan protocol works erratically, it seems that control periodically lost. After I returned wiring back to original, the module again works normally. Probably it can be related to my XL7105-D03 module, it works normally without grounding RXEN.
Last edit: 19 Jan 2014 14:14 by vlad_vy.

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 10:32 - 19 Jan 2014 14:33 #18673 by vlad_vy
Replied by vlad_vy on topic Developing a universal module
XL7105-D03 module has A7700 PA, module pin 9(TXEN) directly connected to pin15 A7700 (RXSW), module pin8(RXEN) directly connected to pin14 A7700 (TXSW).

Operation Mode Pin14(TXSW) Pin15(RXSW)
Inhibited________0___________0
TX_____________0___________1
RX_____________1___________0
Sleep___________1___________1

amiccom.weebly.com/uploads/3/9/5/9/39593...v0.2_preliminary.pdf

As I can see, both TXEN and RXEN can't be 0.
void A7105_SetTxRxMode(enum TXRX_State mode)
{
    if(mode == TX_EN) {
        A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x33);   //first to '1'
        A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x31); //second to '0'
    } else if (mode == RX_EN) {
        A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x33); //first to '1'
        A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x31);   //second to '0'
    } else {
        A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x33);   //both to '1'
        A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x33); //both to '1'
    }
}

void A7105_Reset()
{
    A7105_WriteReg(0x00, 0x00);
    usleep(1000);
    //Set both GPIO as output and high
    A7105_SetTxRxMode(TXRX_OFF);
}
Last edit: 19 Jan 2014 14:33 by vlad_vy.

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 14:45 #18679 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
we spend almost no time in the 0,0 state, so that is unlikely related, but you should try making the fix anyhow. Also, try turning off telemetry on the a7105. The docs you posted do not indicate how quickly the A7700 can switch from tx to rx, and it is possible we aren't giving it enough time.
Or in the case of the hubsan protocol, it looks like there is a typo in the code:
line 396 should be:
        if (++txState == 8) { // 3ms + 7*1ms
            A7105_SetTxRxMode(TX_EN);
            txState = 0;
        }

Please Log in or Create an account to join the conversation.

More
19 Jan 2014 14:48 - 19 Jan 2014 14:48 #18681 by PhracturedBlue
Replied by PhracturedBlue on topic Developing a universal module
And to answer your question, for currently supported protocols, there is no reason to change the wiring. from the hard-wired solution. It may be in the future we'll have protocols that need it (frsky would be one if it worked). Hubsan telemetry is probaly more reliable with the LNA powered up, but it obviously isn't that important as no one has noticed so far
Last edit: 19 Jan 2014 14:48 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

Time to create page: 0.091 seconds
Powered by Kunena Forum