![\"\"](\"https:\/\/majek.sh\/wp-content\/uploads\/2013\/01\/transmitter-584x480.jpg\" "\\"DYI"){kind=spacer}
<\/a><\/p>\nBLOCKS!<\/h1>\n
The gist of this project is: BLOCKS!
\nFor each model you have some sticks, pots, switches and output channels. Between inputs and outputs there is more or less flexible ‘black box’.
\nIn my project you could define exactly what is in this ‘black box’ by connecting math blocks together in absolutely free way.<\/p>\n
Blocks could do:<\/p>\n
- \n
- trims<\/li>\n
- reverse<\/li>\n
- add<\/li>\n
- substract<\/li>\n
- negate<\/li>\n
- expo<\/li>\n
- multiply<\/li>\n
- convert any analog value to 3 state (for switch conditioning)<\/li>\n
- some casual mixers<\/li>\n
- limits<\/li>\n
- and many more…<\/li>\n<\/ul>\n
Better explanation is just to show some examples, so look at them!
\nFor examples you should only know that channels 0-7 are inputs, 16-23 are outputs, some has special meaning or are reseved but right now it’s not important.<\/p>\nSimple model – as in all entry level transmitters<\/h2>\n
It’s easy:
\n![\"\"](\"https:\/\/majek.sh\/wp-content\/uploads\/2013\/01\/1-ch-simple.png\" "\\"Simple")
<\/a><\/p>\nChannel 0 (CH0) is stick input, value goes into reverse<\/em> block. Another input for this block is CH40 which remebers reverse position. Output of reverse<\/em> block goes to channel 52. Another stage is trim<\/em> block which takes value from channel 52 and adds it to trim value from channel 28. Other channels should be done in similar way.
\nSpecial block reverse<\/em> is in fact a multiply<\/em> block but it’s treaten in special way – second channel connected to it shows automaticly in ‘Reverse’ menu.
\nIn similar way trim<\/em> block is an add<\/em> block which second input shows in ‘Trims’ menu.<\/p>\nLooks easy, isn’t it? So, let’s go ahead.<\/p>\n
Delta or flying wing<\/h2>\n
Another example: delta mixer.
\nAt the beggining let’s write some equations:<\/p>\nleft aileron = ( rudder stick + elevator stick ) \/2
\nright aileron = ( - rudder stick + elevator stick ) \/2<\/div><\/div>\nSo let’s draw blocks to calulate it:
\n![\"\"](\"https:\/\/majek.sh\/wp-content\/uploads\/2013\/01\/delta.png\" "\\"Delta")
<\/a><\/p>\nOk, but this is only mixer, what about trims, reverses etc?<\/p>\n
So, look at real life model:
\n![\"\"](\"https:\/\/majek.sh\/wp-content\/uploads\/2013\/01\/delta-full.png\" "\\"Flying")
<\/a>
\nLooks complicated, but let me explain what’s going on.<\/p>\nA little transformed formula for delta mixer in this case:<\/p>\n
right aileron=0.5*elevator+0.5*rudder
\nleft aileron=0.5*elevator-0.5*rudder<\/div><\/div>\nI think that most people who flies flying wing could confirm that this type of model is very sensitive to elevator moves. One solution for this is to make expo\/DR on elevator channel. But I preffer make elevator just less sensitive in favor to rudder. So, instead of using 0.5 coefficient to multiply values from both channels, I use smaller one for elevator and greater for rudder. If coeficcients sum up to 1, results will be still within allowed range (I already did it on my standalone delta mixer based on ATTINY13).<\/p>\n
Let’s look at above picture. Blocks 1-3 are here to make flexible coefficients. On Block1 input is 1 (CH25) and trim (CH40), so it makes at output (CH41) value in range 0…2 dependent on trim position. It’s too big to further calculations, so we must scale it down using Block2. At it’s output (CH43) we have value in range 0…1. Block3 calculate second coefficient for multiplication (CH44=1-CH43). Blocks 5,7,10,11,12, form a delta mixer with adjustable amplification for both control sticks. After delta mixer, there are reverse and trims blocks to adjust servo direction and neutral point. Near input there are blocks 4,6 and 8 – there are standard trims for fine tuning during fly.<\/p>\n
So, as long as you could make some equations to describe how channel values should be processed, you could make it.<\/p>\n
Enough about blocks:-) Let’t go to other topics.<\/p>\n
Software architecture<\/h1>\n
There are few types of tasks inside transmitter:<\/p>\n
- \n
- critical – generating accurate PPM<\/li>\n
- high priority – get values from inputs, calculate blocks and store results for PPM<\/li>\n
- best effort – user interface (menu, displaying something on LCD, trims, options etc.)<\/li>\n<\/ul>\n
Generating PPM<\/h2>\n
I use hardware PWM generator to make an accurate PPM signal. In best possible way \ud83d\ude42
\nThat’s possible because of using timer in CTC mode and interrupts with right, but not so critical place in time. The point is that writing new value to timer in this mode during generating waveform is effective only for new cycle and doesn’t affect current operation, so it could be calculated and programmed anytime during this period. I calculate it just after end of synchro pulse (in interrupt triggered by this event), so CPU has at least 10000 clocks to do it, and this is more than enough. Because of that, there is absolutely no jitter and pulses are just perfect. \ud83d\ude42<\/p>\nGetting values, calculating it and other things<\/h2>\n
That’s another cool solution here: multitasking in AVR!
\nAfter copying output values to buffer for generating PPM, CPU starts getting analog values from ADCs (using interrupts). They are filtered and recalculated and results are put in input channels. Meantime 2 thing are running: PPM generation using interrups and user interface or other not critical things. When all values from inputs are ready, a task switch occurs. User interface thread is interrupted, state is saved to ram and block calculation task begins. After processing and calculating all blocks, this task ends and switches back to user interface task.<\/p>\nThis way PPM is generated perfectly, calculating blocks is done in high priority thread, and the rest fo time could be used to draw some fancy things on color LCD \ud83d\ude42
\nGreat advantage of multitasking is that during programming user interface I could do whatever I want without bothering myself about timing as long as interrupts are enabled.<\/p>\nMemory<\/h2>\n
I decided to use internal flash memory as main storage for model definitions (blocks, initial channel values etc.). I organized data into containers with headers containing information about model number, contents of container (block, channel, comment…) and length. And one important rule: there could be many containers with the same ‘id’ but only last in memory is valid. It makes updates as simple as writing new version of container at the end of other containers. It also help to reduce flash write\/erase cycles. Only drawback is that memody should be compacted from time to time.
\nBut using trims could fill all flash memory very fast, so I decided to make temporary storage only for channels (4 bytes\/ch) in eeprom. In future there will be possibility to move values from eeprom back to flash. It will be needed to backup\/restore model definitions.<\/p>\nFeatures<\/h1>\n
- \n
- Model memory (maximum 31).<\/li>\n
- Each model comprise of:\n
- \n
- comments, model name is one of them and is mandatory (maximum 256 per model) – they could be assigned to channels and blocks<\/li>\n
- channels, some are dedicated to inputs, some to outputs, the rest could be used for trims, reverses, connections between blocks etc. (maximum 253 per model)<\/li>\n
- blocks, they do math operations on input channels and store result to another channel(s) (maximum 255 per model)<\/li>\n
- block processing order, right now you must manually generate list of blocks in order they should be processed<\/li>\n<\/ul>\n<\/li>\n
- 8 output channels, but it could be increased keeping in mind that output frame should be extended<\/li>\n
- 8 analog inputs, they can be also ‘conditioned’ and used for switches<\/li>\n
- PPM output (super accurate, jitter free, ~11000 steps per channel)<\/li>\n
- internal calculations does on 16 bit fixed point numbers (6+10), it is equivalent of more than 2048 steps<\/li>\n
- serial bootloader, so firmware upgrade could be done using standard usb-serial cable\/interface<\/li>\n
- Colour LCD screen<\/li>\n
- 6 keys for menu navigation<\/li>\n
- Open source! (code will be available soon)<\/li>\n<\/ul>\n
A little bit of history<\/h1>\n
In 2006, when I started to think about R\/C models, I bought cheapest 4 channel transmitter with idea, that if I’ll need more – I’ll make it:-)
\nSomewhere between 2007 and 2008, during discussion on Alexrc forum, idea of very flexible and fully programmable transmitter were born.
\nIdea was to define model inside transmitter using basic blocks (sum, multiply etc) and connections between inputs, blocks and outputs.
\nIn 2008 I made a universal board for my projects using Atmega8L and LCD screen from Siemens S65 phone.
\nIn 2009 I replaced Atmega8L with Atmega88 – it allowed to safely (within cpu specs) increase cpu clock up to 11MHz while still running at 3V. And then real story begins:-)
\nAt the end of 2009 I had some things finished: generating ppm, calculating blocks and basics of user interface (menu, keyboard). And then project stuck for almost 3 years.
\nI tried to make it too universal, and it didn’t worked for UI. During these years I used simple transmitters – there were enough for my planes. But at the end Tricopter<\/a> appeared:-) Problems with arming control board<\/a> and need for more channels resurrected old project.
\nSo, at the end od 2012 i removed some code (mostly UI related), revised some assumption (store model definitions not only in flash, but also use eeprom for this), and project moved forward.
\nI put this board into empty old transmitter bought at about $2, added FrSky DHT module<\/a>, connected all together and right now it could be used in real world:-)<\/p>\nFuture<\/h1>\n
- \n
- Switch to Atmega168 or Atmega328 (I have both and code is ready – it’s only a matter of doing PCB and solder it together)<\/li>\n
- Because right now there is almost impossible to buy S65 LCD display (but I have few \ud83d\ude42 ), I bought another similar one. Plan is to make code supporting also this new display.<\/li>\n
- Change code to run on standard Arduino board based on Atmega328 (check all timings in code and rewrite it to support other cpu frequencies)<\/li>\n
- More code, more features (but not on Atmega88 because I already hit memory limit)<\/li>\n
- Timers, i\/o extender (more inputs, trainer mode)<\/li>\n
- …<\/li>\n<\/ul>\n
<\/p>","protected":false},"excerpt":{"rendered":"
Another one? \ud83d\ude42 There are some other open source transmitter projects, so why did I start another one? At first, I started it in 2009 – there wasn’t too much free options avaliable, ready made transmitters were also very expensive. …<\/span> Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,5],"tags":[38,50,24,26,41,40,13,39],"_links":{"self":[{"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/posts\/624"}],"collection":[{"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/comments?post=624"}],"version-history":[{"count":97,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/posts\/624\/revisions"}],"predecessor-version":[{"id":1156,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/posts\/624\/revisions\/1156"}],"wp:attachment":[{"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/media?parent=624"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/categories?post=624"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/majek.sh\/en\/wp-json\/wp\/v2\/tags?post=624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}