Home made RC transmitter 2.4Ghz

[obor]

Hello,
You may be interested to build you own RC transmitter and receiver as I did.
It is based on Arduino board (and derivatives) and Xbee, it is easy to build.

For the transmitter box, I reused an old radio with it sticks, and all the electronic has been replaced. The receiver is made with a Wee+Xbee.

You will find more informations on my blog:
First tests:
http://effetdebord.blogspot.com/2008/10/transmitter-receiver-prototype-first.html

First fly:
http://effetdebord.blogspot.com/2008/10/premier-vol.html

And the rest of my blog:
http://effetdebord.blogspot.com

It's a great fun to fly with your own radio :)
Olivier

[Acetronics]

Bonjour Olivier,

Beau projet, avec du beau linge ...

dommage que, pour les 2 premières lignes ... :



Le blog que vous recherchez est introuvable



Alain

[obor]

Bonjour Olivier,
dommage que, pour les 2 premières lignes ... :
Alain

Merci, c'est resolu.

[mrdunk]

hi Olivier,
nice work.

i'm currently working on a similar but with AVR ATmega2561 connected to UGWJ4USHN33 modules.

the UGWJ4USHN33 is based on the Cypress CYRF6936 chip and was quite time consuming to get working.
my system is ready for testing but unfortunately i have been traveling with work a lot recently and have not yet managed a test flight.

i did not use the Xbee modules because is did not like the restrictions of it's packet structure.
did you manage to find a way to get the Xbee to send data directly or are you limited to transmitting when it's buffer is full?

so the beauty of building a RC system this way is it is easy to get data back from the plane. i can currently monitor on board battery voltage and have plans to implement current draw and air pressure (for airspeed and altitude measurements).

it is also easy to save mixer and trim settings on the aircraft rather than having to have multiple configurations on a transmitter.

so anyway, i'll be documenting my work eventually but i'm afraid i have not used my french in 10 years so won't be much use on your open source project.


dunk.

[obor]

Thanks.
Nice to hear from people who have worked on similar project.

Your use of ATmega2561 it is interesting. I am now getting outof space on the Arduino (16kb flash only) so I may take bigger. I have an Atmega 644p (256kb) that I could use, and better an AVR 32bits.

About the Xbee, I used it mainly because of its simplicity. My goal was to make the "coder" part, more than the transmit part. Xbee can work in both direction, but currently I use only transmit.

For the management of the buffer, well obviously the buffer full situation should be rare, otherwise there is too much noise on the channel. I do not really handle this situation, and if it occurs, current packet are simply discarded. But so far when flying, I have not seen any delay.

On my blog, there is also a reference to an opensource project which is not the same thing than my Arduino project. This rcopensource project has recently started, but if you are interested, you are welcome. Most of the people on that list should understand/write English.
cheers,
Olivier

[mrdunk]

yea, i chose the ATmega2561 because it has 2 16 bit timers attached to 3 I/O pins each so i can control 6 servos in hardware without having to worry about servo timing loops.
it has lots of program space too.
i'd recommend it if you have the ability to use surface mount components.

i have not used any of the 32bit AVR range.
is the programing environment the same?
i'm guessing the main advantage is faster execution of code using a lot of maths?


dunk

[obor]

May be I misunderstood. I thought you were using the ATmega2561 for the tramsission part, not the receiver.
In my project, the transmission is numeric, so I transmit the pulse value as numeric value (2 bytes hexa) through the Xbee.
On the receiver side, I used the Atmega168 with two timers, and handle the timings to servos with software. Currently it support 8 servos, but reasonably could go up to 10.

For the avr32, I have not yet tried it. There is an avr32-gcc version available, but it needs to be compiled and looks not so easy to install than the 8 bits avr-gcc. For mathematic, it should be better, but it's true that with the current 10bits ADC, 16 bits would be enough.

[mrdunk]

May be I misunderstood. I thought you were using the ATmega2561 for the tramsission part, not the receiver.
yup. i'm using the ATmega2561 at both ends.
as i'm transmitting in both directions i'm trying to keep the platform as similar as possible at both ends so i can keep much of the code the same on the plane and on the ground.

On the receiver side, I used the Atmega168 with two timers, and handle the timings to servos with software. Currently it support 8 servos, but reasonably could go up to 10.
i like to control servo pulses in hardware if possible as it greatly simplifies timing if you want to use interrupts in your code.
it does mean you need to chose an AVR with the right timers though.
it's a personal preference thing i guess.
if i ever need more than 6 servos then i'll have to resort to software control of servos or change AVRs.


dunk.

[Angelion]

Hi,

I'm also working on almost the same concept, a fully 2.4Ghz digital chain.
Currently using TX module from LP5DSM (I'm waiting my unigen module) and homemade transmitter (PIC24H based + phone LCD).
It should be fully compatible with DSM2 devices, especially the (low cost) remote receiver SPM9545 (the best receiver for my project, I cannot make such PCB myself), it will drive modified servos (and DIY ESC later) via an i2c bus (ya, I don't like PPM).

[obor]

Hi Angelion,
This is interesting.
How do you make the compatibility with DSM2 devices ?
Do you know the protocol they use ?
And for the servo control, have you considered also CAN ?

[JimnAz]

Good Morning Olivier

Have you thought about using the ATMega328? I thas double the memory of the ATMega128.

I too am working on a similar project and will watch this thread for updates.

I am sorry I do not read French so your site reference is not good for me, but the photos were great.

Jim

[obor]

Hey Jimnaz,
My blog is written in english for most parts... :) so you can read it.

[Angelion]

Je n'avais même pas vu que c'était en Francais, honte sur moi :)

[zenoid]

So many french people doing 2.4 GHZ stuffs, got a project myself. I decided not using any 2.4 GHZ existing module. I've just finished routing it. I'am using a CC2520 + CC2591 front end for the 100 mW boost. It seems to be tricky to obtain any good result in term of band occupation but I want to try because of the low price in the end.

[Angelion]

(Ooops, I missed your post yesterday)



This is interesting.
How do you make the compatibility with DSM2 devices ?
Do you know the protocol they use ?


Thanks to my SPI spy, CYRF6936 IC is used in the DSM2 compatible LP5DSM TX (and spektrum remote receiver?), it's the same IC in unigen module (+power amp), further informations soon.


And for the servo control, have you considered also CAN ?
Too complex for this purpose, and I want a really tiny µC for the receiver.

[Angelion]

I'am using a CC2520 + CC2591 front end for the 100 mW boost. It seems to be tricky to obtain any good result in term of band occupation but I want to try because of the low price in the end.

I had planned to use CC2520 too, but it's too complex compared to cypress WirelessUSB IC (and difficult to make DSM2 compatible).

[obor]

Angelion,
When you say DSM2 compatible, do you mean that you can use your own TX with a SPektrum receiver, and/or a Spektrum TX with your own receiver?

[Angelion]

When you say DSM2 compatible, do you mean that you can use your own TX with a SPektrum receiver

Yes

a Spektrum TX with your own receiver?
My receiver will be based on the spektrum remote receiver.

[obor]

Just an update: I have started to look at the AVR32 chip (32bits, 32 IO pins, 512kb Flash, 64kb SRAM, ....) for the next version of the radio to support more settings, mixers, and curves etc.... (http://effetdebord.blogspot.com).
But the use of this chip is more complex that simple AVR8 chips, and preferably need the use of an OS (like FreeRTOS).

I am currently wondering if I should continue to use this new chip (there are some problems with dev environment also), or try another original solution. May be, why not a multiprocessor solution.

Do you have any ideas or comments about what could be the good choice ?
Olivier

[Norman Adlam]

Just an update: I have started to look at the AVR32 chip (32bits, 32 IO pins, 512kb Flash, 64kb SRAM, ....) for the next version of the radio to support more settings, mixers, and curves etc.... (http:://effetdebord.blogspot.com).
But the use of this chip is more complex that simple AVR8 chips, and preferably need the use of an OS (like FreeRTOS).

I am currently wondering if I should continue to use this new chip (there are some problems with dev environment also), or try another original solution. May be, why not a multiprocessor solution.

Do you have any ideas or comments about what could be the good choice ?
Olivier
Obor,

Just a note.. too many ':' in your link - anyone who is interested needs to remove one, i.e. http://effetdebord.blogspot.com

Any other of you guys have detailed 2.4G project data you can share yet? schematics etc? I suspect there are many of us interested, especially if the protocol can be nade compatible to Spektrum Tx / Rx! :D

Cheers

[geotrouvetout]

Hi all,

nice work Obor, but this is a effective cost using an Xbee as receiver, why not using for exemple a Turborix receiver (12 €) and just keeping the RF section and doing decoding with a PIC or Atmel, the Turborix receiver comes with an extended antenna module with 3 wires perhaps there is a RF section in this module in this case nothings can't beat the price for two receivers.
I think the (or your goal) is to have a cheap (the price of course) 2.4GHz and home made radio that can be compatible with some brand on the market, like zenoid told us because of the low price in the end.

Géo ;).

[Angelion]

obor: try PIC24, a really fast 16bit µC. Exists in low pin count version, easy to handle and can manage all the necessary curves and mixing for our toys ;)

Receiver side, my SPM9545 will be shipped soon, the µC code runs already in simulator (ATTINY2313).
Total cost of my 8ch DSM2 receiver (10 or 12 bit resolution): 20€ .. I hope :D

[obor]

Hi all,

nice work Obor, but this is a effective cost using an Xbee as receiver, why not using for exemple a Turborix receiver (12 €) and just keeping the RF section and doing decoding with a PIC or Atmel, the Turborix receiver comes with an extended antenna module with 3 wires perhaps there is a RF section in this module in this case nothings can't beat the price for two receivers.
I think the (or your goal) is to have a cheap (the price of course) 2.4GHz and home made radio that can be compatible with some brand on the market, like zenoid told us because of the low price in the end.

Géo ;).

Thanks geotrouvetout.
My intention is not to make a low cost RC, but to try some ideas I have in mind about new features. The Arduino chip has not enough power to test some of them, but this is no surprise.
Regarding turborix, your idea is interesting. It can make a cheap sending/receive module. But I don't see how the receiver could be split, without doing some reverse engineering between the RF and microcontroller.
Olivier

[obor]

obor: try PIC24, a really fast 16bit µC. Exists in low pin count version, easy to handle and can manage all the necessary curves and mixing for our toys ;)

Receiver side, my SPM9545 will be shipped soon, the µC code runs already in simulator (ATTINY2313).
Total cost of my 8ch DSM2 receiver (10 or 12 bit resolution): 20€ .. I hope :D
Hey Angelion,
Is it PPM signal going out of SPM9545 ?

[cstratton]

I think the output from the remote receiver is some kind of serial protocol - I2C or even "serial" (as in asynchronous). This is the output from a microcontroller that they put next to the cypress chip (or possibly in some versions, a cypress microcontroller core in the same chip as the RF circuitry)

Has anyone managed to make a DSM compatible receiver by talking directly to the cypress chip (unigen module or otherwise) over SPI yet?

[mrdunk]

Do you have any ideas or comments about what could be the good choice ?
so what is your main constraint on the AVR8?
if it is limited program space then there are lots of bigger 8bit AVRs to choose from.
for example the ATmega2561 has the same amount of flash memory as the 32 bit AVR range and has more SRAM and EEPROM.
(have you found AVRFreaks.net's comparison chart yet: http://www.avrfreaks.net/index.php?module=Freaks Devices&func=devCompare? )

if you are starting to run out of processor speed then the solution is not so straight forward.
a faster processor is one option but i think a single high spec AVR Mega should be more than capable of doing everything you need.
i have not read up on the AVR32s but i suspect they will only be of much faster if you plan to do lots of calculations with numbers larger than 8 bits.

May be, why not a multiprocessor solution.
i have successfully used multiple AVRs on a single project before but it greatly increases the complexity of the project.
the key is getting a robust communication method working first and then building the rest of your project on that.
my effort along these lines is here: http://mrdunk.googlepages.com/electronics
while it's a lot of work getting reliable communication working, it makes it very easy to add more functionality to a project.

the next version of the radio to support more settings, mixers, and curves etc....
for the RC system i'm working on i save trim settings, mixer curves etc on the receiver rather than the transmitter.
each plane will have it's own receiver and that receiver will have a microcontroller so why waste resources on the transmitter's microcontroller saving settings that only apply to one plane?
likewise each plane only needs one set of settings so no need to have complex menus for choosing which configuration.

so i'm new to RC, i don't own any normal transmitter equipment so i don't really know how the "normal" way to do this is but this method makes a lot of sense to me and frees up a lot of microcontroller resources.

for trim settings i have a button on my controller that saves the current control surface position as the default.
the transmitter just sends the status of the button, it's the receiver that does all the rest of the work.

the one thing i don't have worked out yet is exactly how i will set up channel mixing.
i would like it so the user sets them up on a computer spread sheet and uploads them to the receiver's flash memory via the transmitter...
i don't have this bit fully worked out yet and for now they are just hard coded into the receiver's firmware.
eventually the receiver will be able to take inputs from sensors (eg, rate gyros, electronic compass, etc) and use the same mixing rules to affect servo position.

Any other of you guys have detailed 2.4G project data you can share yet? schematics etc? I suspect there are many of us interested, especially if the protocol can be nade compatible to Spektrum Tx / Rx!
yea, i'll get round to documenting mine eventually. been having too much fun learning how to fly. and gluing broken foam.
any day now...
(realistically you can expect some docs from me sometime shortly after the new year.)
i have not done full range tests yet but it works very well so far.
as i already mentioned though, i have never used commercial RC equipment so have nothing to compare it to.
i'm afraid i have no plans to reverse engineer the Spektrum protocol though as one of my requirements it 2 way communication.

dunk.

[obor]

Hello Dunk,
Thanks for your very detailed suggestions :)

so what is your main constraint on the AVR8?
if it is limited program space then there are lots of bigger 8bit AVRs to choose from.


Main constraints currently is SRAM size, and then Flash size. Arduino has only 1KB SRAM and 16KB flash. With some AVR chips, SRAM extension is possible, but stack can't extend to the extension and has to stay within the internam SRAM limit. When using an object language, you quickly reach the limits.


(have you found AVRFreaks.net's comparison chart yet: http://www.avrfreaks.net/index.php?module=Freaks Devices&func=devCompare? )

Thanks for the pointer.


the key is getting a robust communication method working first and then building the rest of your project on that.

Agree. Is there any reason why you choose in your project I2C and not SPI ? It looks (but I may be wrong) that SPI is more efficient and less costly for the processor.


http://mrdunk.googlepages.com/electronics

Very nice pages, and nice work.


for the RC system i'm working on i save trim settings, mixer curves etc on the receiver rather than the transmitter.

I think you can't go too far in putting settings in the receiver. This is fine for stuff that will not change during a flight as reversing, course limit, servo speed... but for mixing curve, course, etc.... you should have the possibility to tune them during the flight. For instance, it is very convenient to tune the elevator course while flying without having to land each time.


for trim settings i have a button on my controller that saves the current control surface position as the default.
the transmitter just sends the status of the button, it's the receiver that does all the rest of the work.

This is what is often called "auto trim". I don't know any commercial radio which have this. Yes, it is a nice feature.


the one thing i don't have worked out yet is exactly how i will set up channel mixing.
i would like it so the user sets them up on a computer spread sheet and uploads them to the receiver's flash memory via the transmitter...

Yes, this is an interesting approach. There is the turborix radio also which has a similar approach, but more based on graphical interface. On the yahoo group "rcopensource", we have defined a simple programming language which should allow to program almost anything in the radio and quite simply. We have online documentation, but not yet in English (in French currently), sorry.
Olivier

[mrdunk]

Main constraints currently is SRAM size, and then Flash size. Arduino has only 1KB SRAM and 16KB flash. With some AVR chips, SRAM extension is possible, but stack can't extend to the extension and has to stay within the internam SRAM limit. When using an object language, you quickly reach the limits.
ah. i understand.
while i could never imagine you running out of flash on one of the bigger AVRs the limited SRAM would be an issue.
i guess it is a reason to avoid object orientated programming on an embedded platform.

Is there any reason why you choose in your project I2C and not SPI ? It looks (but I may be wrong) that SPI is more efficient and less costly for the processor.
yes, SPI is generally better if you know at the start how many devices you are going to connect to a bus. each SPI device needs an enable pin (SS) connected to a bus master.
but on that robot platform i wanted to be able to just add more modules to the bus without having to alter the bus master in any way. just connect the power and 2 data lines. less reliable but more flexible.

i've been meaning to read up on the CAN bus as i believe it's a more robust, higher bandwidth communication method but without the need for enable lines. i have not got round to it as yet though.

I think you can't go too far in putting settings in the receiver. This is fine for stuff that will not change during a flight as reversing, course limit, servo speed... but for mixing curve, course, etc.... you should have the possibility to tune them during the flight. For instance, it is very convenient to tune the elevator course while flying without having to land each time.
i agree but i don't see why this still can't be stored on the receiver.
button presses that are intended to alter parameters are transmitted to the receiver along with the control data.
as bandwidth is not a limiting factor at 2.4GHz i don't see any problem with this approach.

it could be argued that this approach complicates things if the operator wants to read these settings as you will have to broadcast the setting back to the transmitter for display but i think it is worth the overhead to have all mixing done at the receiver end so sensors can easily added to the mix.

in case you have not guessed from my interest in robotics, my ultimate goal here is to have a platform that can be fully autonomous or radio controlled or a mix of the 2 all using the same simple hardware.
while this obviously influences my desire to have receiver end doing most of the hard work i am convinced it is a useful approach for anyone who wants to add a rate gyro to their system and be able to adjust it's gain on the fly.

but then again, i'm new to this so what do i know?
please fell free to educate me if i'm missing something.


dunk.

[obor]

i guess it is a reason to avoid object orientated programming on an embedded platform.

Well yes and no. If you don't pay attention, Object programming can consumme a lot both in performance and in memory. But If you pay attention, then it is really powerfull and simplify a lot complex design.


i agree but i don't see why this still can't be stored on the receiver.
button presses that are intended to alter parameters are transmitted to the receiver along with the control data.
as bandwidth is not a limiting factor at 2.4GHz i don't see any problem with this approach.

Well, you may be right. It depends how many additional informations are need to transfer to the receiver in addition to the sticks, switch and cursors position. On my project, I used the Xbee at 38400. It's ok, even with CRC adn stuff. Howver, at higher rate, I have no idea how the Xbee behaves ? May be on long distance, many data are lost when using high transfer speed, and when you're flying a plane you don't want this.


it could be argued that this approach complicates things if the operator wants to read these settings as you will have to broadcast the setting back to the transmitter for display but i think it is worth the overhead to have all mixing done at the receiver end so sensors can easily added to the mix.

You don't need that, if your receiver is always programmed from the same source.


in case you have not guessed from my interest in robotics, my ultimate goal here is to have a platform that can be fully autonomous or radio controlled or a mix of the 2 all using the same simple hardware.

Problems looks to be very similar to RC. The difference is that in your case, sometime there is a human behind, sometimes not. Future is may be command assistance to help the pilot in any action he could make.

[komer]

can you translate "Realisation" section on your website into english?really dont know french..very interesting project!

[obor]

can you translate "Realisation" section on your website into english?really dont know french..very interesting project!

I can't find which page your are talking about. I start to have too many :)
Which url is it ?

[komer]

http://www.o24rcp.org/articles.php?lng=fr&pg=77

will try to make this like you ,so little english help would be great:)

[obor]

Ah, you mean the o24rcp site. Well, I can probably help, but I am not good enough at electronic english words. May be you can check with the web master of that site.

[komer]

can you put PCbs here(negatives) and part lists?
hex file and advices about making this?

ive send an email to webmaster...

ps.any other cool site you have with this themation?

[Powerbook]

Hi all,

I'm Christophe from O24RCP Project.

You could find on O24RCP web site all you need to build an 2.4Ghz module & receiver (PCB, Hex file, ...).

Yep, all web pages are in French... i will try to make a page in english with all informations need to build and use O24RCP (but my english is not very good, sorry).

O24RCP use Atmel Avr & Maxtream Xbee and AvrGcc tool chain.

We have a "large" users community now with very nice contributors (PCB module for Futaba/Jr/Graupner/Multiplex, new receivers design (up to 12 channels), downlink dataloger system in study, ...), it's a very fun project.

A forum is open, you could post in english ;-)

If you are in holiday in France on May, we are very happy to see you in the O24RCP "Camp" (next 23 et 24 May near Nantes) ! all DIY R/C projects are welcome !

O24RCP : http://www.o24rcp.org
Forum : http://forum.o24rcp.org

See you soon.

Christophe.

[AndyKunz]

wrong thread

[obor]

Hello,
Some news on this project: I made a case in alu for the next version.
More pictures on my blog: http://effetdebord.blogspot.com/2009/02/transmitter-case-alu-prototype.html

[obor]

Hello again,
For the summer, I made a small TX based on a low cost TX for the box and sticks, an Assan module for the transmission and an Atmel AVR 644P for the mixers and core. The software is RCHv2 (my own) written in c++, and still in development.
See attached pictures.

New transmitter (http://effetdebord.blogspot.com/2009/05/home-made-rc-for-summer-and-travels.html)

first flight (http://effetdebord.blogspot.com/2009/05/first-flight-with-rchv2.html)

More details ( http://effetdebord.blogspot.com/2009/05/short-howto-build-of-rchv2.html)

Olivier

[GFBurke]

nice.

[ishady]

Great thread here
Already read the blog too...very generous explanation
Since I am no electrician (I ask my tech friend to solder my esc-motor..LOL) do you plan selling any affordable RC tx? Any 4 or 6 non-programmable channel?
Thx

[chewytm]

I am very interested in the Spektrum compatible rx. It would be nice if we can make cheap compatible rx for ourselves.

chewy

[obor]

Great thread here
Already read the blog too...very generous explanation
Since I am no electrician (I ask my tech friend to solder my esc-motor..LOL) do you plan selling any affordable RC tx? Any 4 or 6 non-programmable channel?
Thx

Thanks ishady.
Selling an affordable RC tx is very tough these days with chineese production, especially 90$ turningy radio. Any selling plan has to be very strong to survive. So I still think that an opensource approach for the RC community is a good way to go. Just like it happened on "crrcsim" simulator, which is open source, and still one of the best simulator for gliders (including F3F).
Olivier

[obor]

I am very interested in the Spektrum compatible rx. It would be nice if we can make cheap compatible rx for ourselves.

chewy

I think that to make a Cheap compatible Rx is almost impossible. The price on electronic components when buying small quantities. You need to buy huge quantities to get good prices.
Rx compatibility is a problem in 2.4Ghz. Each vendor has its own "algorithm" for transmission. But, the cost of modules has go down, see Assan for instance. So it becomes more and more possible to own several modules, depending on the receiver you use. If you fell the receiver prices is too high, just buy a module from a vendor which sell low cost receiver.
Olivier

[Norman Adlam]

Hi all,

I'm Christophe from O24RCP Project.

You could find on O24RCP web site all you need to build an 2.4Ghz module & receiver (PCB, Hex file, ...).

Yep, all web pages are in French... i will try to make a page in english with all informations need to build and use O24RCP (but my english is not very good, sorry).

O24RCP use Atmel Avr & Maxtream Xbee and AvrGcc tool chain.

We have a "large" users community now with very nice contributors (PCB module for Futaba/Jr/Graupner/Multiplex, new receivers design (up to 12 channels), downlink dataloger system in study, ...), it's a very fun project.

A forum is open, you could post in english ;-)

If you are in holiday in France on May, we are very happy to see you in the O24RCP "Camp" (next 23 et 24 May near Nantes) ! all DIY R/C projects are welcome !

O24RCP : http://www.o24rcp.org
Forum : http://forum.o24rcp.org

See you soon.

Christophe.
Christophe,

Can any of us here help you with the 'technical' parts of the translation?

I was thinking that I could start by running each page through Babel fish, and then tidying up the translation into 'proper' English (as best I could).
I'd leave anything that I couldn't understand as a marked question, for cleverer people to assist with. :D

Have you an email address that I could send the translated page attempts to?

Cheers,

[obor]

Christophe,

Can any of us here help you with the 'technical' parts of the translation?

I was thinking that I could start by running each page through Babel fish, and then tidying up the translation into 'proper' English (as best I could).
I'd leave anything that I couldn't understand as a marked question, for cleverer people to assist with. :D

Have you an email address that I could send the translated page attempts to?

Cheers,

Please use another thread to discuss this, O24RCP is a different project.
Thanks in advance,
Olivier

[Angelion]

I think that to make a Cheap compatible Rx is almost impossible. The price on electronic components when buying small quantities.

I agree, that's why I'm using SPM9545 module, you cannot make such RX with homemade materials (or with very high skill).
I'm waiting some components from China before to post my really cheap TX DSM2 compatible module (15€) with its RX SPM9545 daughter card.

A motobike accident has delayed the project :(

[jafoca]

I would say that there are plenty of reasons to do DIY electronics aside from price... I for instance am working on an XBee solution because my Spektrum DX7 does not offer enough proportional channels, and I think I can achieve longer range with better antennas than spektrum uses...

Add to that unlimited programability, and the potential for auto-pilot, and we have lots of motivation to do it ourselves!

[GFBurke]

What about embedded linux? Cost goes up per user, but having something either written (eventually Android once things are small/fast enough) for a debian distro (feather, dsl etc) could really open door for the FLOSS community to write to|update|release TX code.

Backup, copy, download etc.

I think it could be done today, but at a real cost for nano ITX turn-key solutions. However, since we can install linux and run full commands on our old ipods....

[ishady]

I would say that there are plenty of reasons to do DIY electronics aside from price... I for instance am working on an XBee solution because my Spektrum DX7 does not offer enough proportional channels, and I think I can achieve longer range with better antennas than spektrum uses...

Add to that unlimited programability, and the potential for auto-pilot, and we have lots of motivation to do it ourselves!
Do you think it could reach range 5 km or so ?
I am looking for a reasonable priced RC system for my UAV
Thx

[obor]

What about embedded linux? Cost goes up per user, but having something either written (eventually Android once things are small/fast enough) for a debian distro (feather, dsl etc) could really open door for the FLOSS community to write to|update|release TX code.

Backup, copy, download etc.

I think it could be done today, but at a real cost for nano ITX turn-key solutions. However, since we can install linux and run full commands on our old ipods....

Why not, may be using Linux will attract more developpers and as you said Nano ITX are becoming more affordable.

[obor]

I'm waiting some components from China before to post my really cheap TX DSM2 compatible module (15€) with its RX SPM9545 daughter card.

Very interesting .
Do you plan to enter pure PPM signal (0-5v) to the module ?

[Angelion]

No, signals come from the mixing module, on UART or I2C (like you I build my own Tx).

But an extra module can be made for that purpose (or another firmware).

Je posterai sur ORC quand j'aurai fini ;)

[obor]

Je posterai sur ORC quand j'aurai fini ;)
What is ORC ?

[Angelion]

Oops, O24RCP, I thinked OpenRC ...

[obor]

Oops, O24RCP, I thinked OpenRC ...
Do you mean RCopensource (http://sourceforge.net/projects/rcopensource/) or something else ?

[obor]

In attachment, some screenshots of the PC application to configure the radio.

More details on my blog: http://effetdebord.blogspot.com/

[JimnAz]

@OBOR

Hello and good afternoon,

I just visited your blog and am very impressed with and interested in your Transmitter. Is this a project you would be willing to share your firmware and computer configuration?

I was not able to find a reference or details to the project other than the photos.

I have the Atmega 644P and several other parts already and am most curious how to obtain the rest of the information to be able to build a version of what you have built.

Thank you in advance for any direction you may provide.

Jim

[obor]

@JimnAz
Thanks for your interest. Currently there is no much more than my blog, I spent most of my free time to do the development. I will add more details in the future for sure.
Regarding the firmware and the PC software, yes I will share them. Both are still evolving, ideally they should be open sourced so that anyone can use them. Meanwhile, I can send the current version of both, just contact me on my private box of this forum.

Regarding hardware, there is not yet material list, but here are the main parts:
- atmega 644p,
- crystal 16Mhz
- 2* capacitor 22pf,
- 3*R 3.3K,
- 3*R 1.8k,
- Micro SD card with its socket,
- ldo voltage regulator 5v,
- 2* capacitor for ldo 5v,
- voltage regulator 3.3v,
- some connectors like this: TYCO ELECTRONICS / AMP - 1-826629-0,
- an old or low cost RC box with sticks,
- the transmision module currently can be Assan or Xbee. Xbee O24RCP protocol is supported, and also the RCHome v2 protocol. Note that in both case you'll need to make your own receiver. Any other modules like Spektrum is likely to be usable, as long as it accepts standard PPM signal as input.
- battery: 5 cells Ni-MH, or more.
Note that if you put more than 5 cells, you'll need to add a thermal dissipator to the 5v regulator.

Some pictures here of the "hacked" v2:
http://effetdebord.blogspot.com/2009/05/short-howto-build-of-rchv2.html

If this still lacks informations (I have no doubt that it does), please just ask on this thread.
Thanks,
Olivier

[JimnAz]

@JimnAz
Thanks for your interest. Currently there is no much more than my blog, ........ PC software, yes I will share them. Both are still evolving, ideally they should be open sourced so that anyone can use them. Meanwhile, I can send the current version of both, just contact me on my private box of this forum.

Olivier

Hello Olivier;

PM sent. Thank you again in advance

James

[obor]

Hi,
Jusr some news about RCHv2 project. Last week end I did the first fly with a bigger model, an aerobatic glider with 6 channel servos. The PC configuration software allows to configure new mixes that can be named, so I could configure the flaps (with ailerons to volets), the snap (elevator to ailerons + volets) and the butterfly (airbrake with ailerons + flaps + elevator compensation). I had to make some new changes to the software, but it is gently growing with more capabilities.

At the end of the flight, my battery (an old thing that I should have replaced) became dry and deliver only 3.2v.... Fortunately, the Assan receiver worked even at the low voltage, but the servos could only work more for some millimeters, one aileron was not moving at all...
Hopefully, I could land without damage.
see also: http://effetdebord.blogspot.com/2009/07/aerobatic-glider-and-rchv2.html
Olivier

[obor]

The firmware and the configuration tools are available.

The Hex image to flash and the PC gui application with examples is here (http://oborlinux.free.fr/RCHome/rchv2.tar.gz) . See README for more informations on how to flash and use.
The short howto build the TX is still here (http://effetdebord.blogspot.com/2009/05/short-howto-build-of-rchv2.html) .

Features:

- 8 input ADC (sticks, pots),
- more than 8 switches input,
- 8 channels control,
- configurable input (analog, switch)
- configurable mixes,
- reverse, limit, subtrim, pulse
- model storage on SD Card
- configuration application on PC
- no lcd display,
- signal compatible PPM, O24RCPv1, RCHv2

[jaydag77]

Just finished reading through the thread and am very interested and impressed with the work produced! I (also) am trying to develop a custom transceiver setup but am using the cypress rf devices (which I believe is what is used in the spectrum dsm2 devices- and dsm1 I think too).

I have been reading through various forums and elsewheres cause I'm currently trying to find as much info on the DSM2 protocol as am able before I go ahead and try to figure it out myself (why re-invent wheel..?),, I would also like my controller unit to be able to support multiple protocols other than my own custom (and hopefully dsm2).

anyways,, in particular obor you have done some great work,, I am planning to read through your code hopefully sooner than later and am counting on finding some inspiration embedded though will be only in an abstract sense!

[obor]

Hello jaydag77,
Thank you for encouragment.
You started a big work for Doing DSM2. It is nice idea.

Another idea also would be to do an "open source " protocol based on Unigen and/or cypress hardware. A kind of mix of FHSS and DHSS protocol, with retransmission back to the TX. We are not so far currently from such Open procotol, several persons on rcgroups have already played a lot with this unigen/cypress and used for their own RC.
We could define technically how it will works. Then define an Interface so that a TX "Coder" can use it. Then write some source code freely available somewhere.

[Alan Hopper]

obor,
great work, I find it adds a certain edge to flying when you know you are responsible for some of the link between your fingers and the plane. I am very interested in helping developing open source protocols to communicate between rc components. Once you have two way comminication all sorts of possiblities open up. Such protocols could cover everything from using your mix definition software with any radio to relaying the live positions of planes in a club air race over the internet. Keep up the good work.
Alan

[obor]

Thank you Alan.
I wonder if there would be more people interested in this dicussion of Open protocol. There is surely transmission gurus on rcgroups who could also provide ideas, hint.
I am thinking of FHSS/DHSS for instance. Should the protocol use only 2 frequencies such as DSM2, or five such as Jeti, or more such as Futaba? At what period should the system switch from one 2.4 frequency to the other ? How to ensure the best robustness of the link ? Should it be a peer to peer or a broadcast ? Is encoding needed ? should it be a limitation in the number of channels ?
And also, what is possible to do with the current hardware (cypress, jennic, etc...), define a simple interface that could be easily implemented, etc....

[obor]

Source code of RCHv2 is now available at rcopensource gitweb (http://rcopensource.git.sourceforge.net/git/gitweb.cgi?p=rcopensource), and/or by git:
git clone ssh://@rcopensource.git.sourceforge.net/gitroot/rcopensource

[iter]

Congratulations on publishing your code Olivier.

Thank you Alan.
I wonder if there would be more people interested in this dicussion of Open protocol. There is surely transmission gurus on rcgroups who could also provide ideas, hint.
I am thinking of FHSS/DHSS for instance. Should the protocol use only 2 frequencies such as DSM2, or five such as Jeti, or more such as Futaba? At what period should the system switch from one 2.4 frequency to the other ? How to ensure the best robustness of the link ? Should it be a peer to peer or a broadcast ? Is encoding needed ? should it be a limitation in the number of channels ?
And also, what is possible to do with the current hardware (cypress, jennic, etc...), define a simple interface that could be easily implemented, etc....
I have an interest in developing protocols and interfaces. I notice that my focus is primarily one level up the stack from the issues you bring up--a design feature of Polyglot is that it is agnostic to the physical link and coding scheme. This said, I want to at least implement your protocol in Polyglot and provide feedback on it.

Ari.

[obor]

Thank you iter.

This said, I want to at least implement your protocol in Polyglot and provide feedback on it.
Ari.
I am not sure which protocol this is (the frame with bytes length + crc) ? But, feel free to use it and experiment, or define your own. Bringing feedbacks together will surely help to move forward. At some point of time, we may all agree on a good way to do it, write some code and expose it to the community.
Olivier

[iter]

I am not sure which protocol this isThe one you eventually come up with.

Ari.

[obor]

<editing>

[PLMS]

Thank you Alan.
I wonder if there would be more people interested in this dicussion of Open protocol. There is surely transmission gurus on rcgroups who could also provide ideas, hint.
I am thinking of FHSS/DHSS for instance. Should the protocol use only 2 frequencies such as DSM2, or five such as Jeti, or more such as Futaba? At what period should the system switch from one 2.4 frequency to the other ? How to ensure the best robustness of the link ? Should it be a peer to peer or a broadcast ? Is encoding needed ? should it be a limitation in the number of channels ?
And also, what is possible to do with the current hardware (cypress, jennic, etc...), define a simple interface that could be easily implemented, etc....

Hi all,
I've just popped up out of nowhere more or less..
The talk of Open Source got my attention, I too feel the time is right for this as the ready made hardware is getting so cheap to buy. I've myself had thoughts of reverse engineering the one of the cheap available 2.4Ghz TX/RX modules like ASSAN or CORONA with 'our' own transmission protocol. The hardware from these Chinese sources is great, but the firmware.... Well let me not start on that.

On the above post. I know from experience (not mine) that it's easier to implement DSSS transmission than FHSS. DSSS seems to need less CPU time to decode and manage the RF chips. While FHSS seems better for RC use on paper, experience has shown that well implemented DSSS is so close to bullet proof that FHSS is not a big advantage (if at all). So I'd go DSSS for any starting project. Probably two RF channels, alternate frames across both so only link delay is effected by an interferer on one channel. Bare in mind that DSSS can tolerate a LOT of interference on channel.
I have access to proper RF test equipment for the 2.4Ghz band and am happy to get involved in RF testing on any project.

Cheers,
Martin

[obor]

Hi PLMS,
Thanks for your proposition. Testing will be very valuable in this kind of project.

Regarding DSSS only, you said that it can tolerate a lot of noise. From what I heard, it looks *not* to be as strong a FHSS or Futaba like protocols. It's may be just a bad luck, but some people have experience in some very noisy situation that FHSS is the only thing which works.
Anyway, it does not matter, the Open Source protocol ideal should probably be a combination of both, with a configurable max number of channels. From 1 to N, 1 in the case of Xbee , N (>10) in the case of Futaba, 5 in the case of jeti, etc....

Then, what algorithm to choose to hop from one frequency to the other ? How to guarantee that receiver can always and quickly retrieve its synchronization ? Should the TX always transmit (power consumming) or just when needed ?

[vintage1]

I have decided also to pop in from nowhere.. as its a dull windy day, the workshop needs cleaning, and the cricket is over till Thursday, and..

Anyway, it seems to me that there are a lot of things that need not impact one upon another. The actual stick to servo chain breaks down into several boxes so what is actually needed is ..mm..four *Interface* standards, leaving how they are implemented up to whoever...
Black Box 0
A collections of sticks, trims and switches and a power supply in a case.

Interface One.

A generic interface between a set of sticks, trims and switches and the TX CPU encoder. I suggest this should be something like 2.5v +- 1v DC on each input.

The CPU may or may not feature mixers, memory, an LCD screen, and suchlike, but that's what it should accept as input, and process.

Whether it runs Linux or whatever, is a moot point., its a 'black box' and its job is to turn all that lot into..

Interface2
Some sort of 0-5v nominal digital serial stream of channels. Now traditionally that's been a PPM channel, but USB might be better. Its bidirectional for a start.. and most PCs can drive it, which means you could in fact have a load of computer software driving the next block, which is the TX RF and encoder (and if bi directional., decoder).

so

Black Box 2
Is something that takes our defined USB stream, and turns it into RF energy in some way. That communicates via...

Interface 3

Our RF transmission protocol. This might be one of many fixed channel (cheap) twin channel (better) full hopping(even better?) but the only requirement here is that as long as the TX and RX modules are a matched pair we end up with :-

Black box 3
A receiver capable of outputting our reconstituted USB-like serial stream out of its anterior orifice. into..

Interface 4
Our servo interface. Currently PPM, with no real hope of change at this time. Also if sensors are onboard, possibly a 2.5V+-1v signal that goes via a back channel back to the transmitter for recording or display purposes.

If the specs are tied down, then you could pick from any matched pair of tx/rx black boxes and plug them into a variety of encoder and indeed cases and stick arrangements. Or a computer running software to drive the USB. Nice modular stuff.

If you settle on a common RF standard, or perhaps 3 - simple, twin channel, and FHSS, then as long as the receivers match the transmitters, or indeed as long as the stuff can detect what is happening and adapt to it, then there should be no problem with interoperability.

This may take more CPU on the receivers, but that isn't the end of the world.

Also, splitting it like this means that different people can work on each black box. For example, a 'black box' element is the USB stream to servo PPM. That's a nice exercise in software. A 'Thing' that plugs into a PC and wiggles servos in sympathy with onscreen sliders etc.

Likewise the TX encoder- a Thing that takes voltages and turns them into a USB stream that you can read and do stuff with. Like fly flight simulators..

[iter]

Good thing cricket is over till Thursday! Thank you for sharing your ideas and observations.

I notice that your CPU (black Box 1) combines and ADC with an optional mixing module. I wonder if separating these two can make the system more modular. I prefer to have the mixing, displaying, & memorizing CPU accept a digital input and produce a digital output in the same format. This way I can unplug it and wire the ADC directly into the next stage, or replace it with a different implementation, or a PC. I want the CPU to be transparent to the protocol, so that I may plug in 0, 1 or any number of filtering CPUs in this chain all the way up to the RF deck.

I notice that PPM and USB, which you propose to interchange, describe different levels in the protocol stack. USB is more like FM than PPM. You can send serial over USB, or a HID/joystick protocol, or a proprietary protocol. Emulating a USB joystick has the advantage of seamlessly working with flight sims, but that protocol is unidirectional, and the PC can't drive a TX through this protocol. A possible additional advantage is being able to use USB joysticks to drive your black box, but this is more difficult as it requires a USB host implementation in the black box, which significantly jacks up the price of admission.

I agree that how the RF stage works can be orthogonal to the rest of the system. It can be transparent to the levels above it in the stack. The RF section in the RX can demodulate the serial protocol and make it available to downstream processing, or you can plug in a wire between the TX and RX and bypass the RF link. The RX can feed its serial stream directly to an DAC (involving perhaps a PPM servo driver, or a PWM actuator or motor driver), or pass it though 0 or more filter stages to do its own mixing, centering, etc.

Ari.

[obor]

Iter, I agree with your view to split things on most points. One comment though about the mix stuff: It should not be correlated with the inputs. Agree. But it also should not correlated with display, configuration system. Mix takes their input from some kind of command language" that can be provided in many different way: from a lcd, a PC, or even from information returned back by the receiver.

This is my second point, to not forget that datas may come back from the receiver, and that something will have to deal with that.

I had some thought also about a possible protocol for RF in 2.4Ghz. But some parts are not obvious, like how to easily resynchronize an Rx on a TX given a channel range ?

[iter]

Another feature I want in the protocol is the ability to interrogate components and link qualities. In a two-way setup, I want to say,
"I am Ari's brown transmitter. I want to talk to Ari's Slow Stick, the one with the Snoopy on it," to which the Slow Stick can respond,
"I am Ari's Slow Stick, the one with the Snoopy on it. Link quality 85%."
In a one-way, PPM system with a software-controlled RF module, a-la Royal Evo, I want to say,
"Switch to 72MHz, Channel 50," and hear a confirmation or a "not able."
Finally, with an opaque RF module a-la Futaba or Assan, I want to at least know that one is present.

One component in this system can be an RF module multiplexer--several dumb RF modules plug into the device, and the device enables one of them based on the serial commands it receives.

Ari.

[iter]

I had some thought also about a possible protocol for RF in 2.4Ghz. But some parts are not obvious, like how to easily resynchronize an Rx on a TX given a channel range ?I am not clear on the problem you describe with "resynchronize."

Ari.

[obor]

Another feature I want in the protocol is the ability to interrogate components and link qualities.

There is also the interrogation between TX and RX to make sure they are the right things talking together.
TX current model configured with "my wonderfull glider" asks RX: Are you "my wonderfull glider" ?
RX acknowledge YES/NO. If NO, then TX talks: "Olivier, are you trying to fly with the wrong model configured ?".

[obor]

I am not clear on the problem you describe with "resynchronize."
Ari.
When the RX start or restart, it has to find on which channel the TX talks to get datas from it (and to check the Tx id). This is what I called "resynchronize", it's just my bad wording :)

[Alan Hopper]

Obor, Ari, Vintage1,
just to throw something else into the mix, the return data path might not be the same as the transmitted one, you could use a spare channel on a conventional system to pass data through the rx by modulating the pulse width and then get data back through a separate telemetry link. Transparent magic should then recombine the data.

Thinking about data links with possible drop outs is a good mental exercise, I spent quite some time struggling with 'liar paradox' situation that means neither side can ever quite know the state of the other side ( i.e. how do I know my ack has been received). Changing channels by agreement is a very tricky thing. My frequency hopping DSSS has worked flawlessly for me, I have a plan to improve it but it is low on the priorities as it just works. For rapid resyncronization at startup or loss of sync, the required hopping rate is related to the number of channels i.e. the more channels the faster you have to hop.

[obor]

Hi Alan,
Would you mind sharing the algorithm (code) you used for your DSSS frequency hoping ? May be you did already in your thread, sorry if this is a stupid question. This could be an interesting step to an opensource RF protocol.
the more channels the faster you have to hop.
Yes, and in my mind, the number of channel should be configurable. Between 2 (1?) and 10 or more. Experience will probably tell the best value to have reasonable resynchro time.

[iter]

There is also the interrogation between TX and RX to make sure they are the right things talking together.
TX current model configured with "my wonderfull glider" asks RX: Are you "my wonderfull glider" ?
RX acknowledge YES/NO. If NO, then TX talks: "Olivier, are you trying to fly with the wrong model configured ?".We are on the same page here, with insignificant differences. I prefer the RX to respond with its full name (or ID) so that the TX can determine that it matches its expectation, but a boolean yes/no serves the same purpose.When the RX start or restart, it has to find on which channel the TX talks to get datas from it (and to check the Tx id). This is what I called "resynchronize", it's just my bad wording :)I think you are talking about frequency-hopping, and how the RX knows what frequency the TX is on just now. This is a different layer in the stack from what I am talking about. I see how this layer can use the same IDs as the layer above it, but they don't have to, and the IDs in your frequency-hopping layer may have different lifecycles than the names I describe. The TX can issue an ID to the RX when they establish a connection, for instance, and use it as long as the link is on, then issue a different ID after you change flight batteries.

Ari.

[vintage1]

Good thing cricket is over till Thursday! Thank you for sharing your ideas and observations.

I notice that your CPU (black Box 1) combines and ADC with an optional mixing module. I wonder if separating these two can make the system more modular. I prefer to have the mixing, displaying, & memorizing CPU accept a digital input and produce a digital output in the same format. This way I can unplug it and wire the ADC directly into the next stage, or replace it with a different implementation, or a PC. I want the CPU to be transparent to the protocol, so that I may plug in 0, 1 or any number of filtering CPUs in this chain all the way up to the RF deck.

I notice that PPM and USB, which you propose to interchange, describe different levels in the protocol stack. USB is more like FM than PPM. You can send serial over USB, or a HID/joystick protocol, or a proprietary protocol. Emulating a USB joystick has the advantage of seamlessly working with flight sims, but that protocol is unidirectional, and the PC can't drive a TX through this protocol. A possible additional advantage is being able to use USB joysticks to drive your black box, but this is more difficult as it requires a USB host implementation in the black box, which significantly jacks up the price of admission.

I agree that how the RF stage works can be orthogonal to the rest of the system. It can be transparent to the levels above it in the stack. The RF section in the RX can demodulate the serial protocol and make it available to downstream processing, or you can plug in a wire between the TX and RX and bypass the RF link. The RX can feed its serial stream directly to an DAC (involving perhaps a PPM servo driver, or a PWM actuator or motor driver), or pass it though 0 or more filter stages to do its own mixing, centering, etc.

Ari.


Yes, yes, and yes!. I only wanted to get people thinking 'modular' here. If we can define modules in terms of the interfaces, and the function, and leave the technology to whoever wants to design it, then things should in an ideal world plug together and work.

I lumped mixing, LCD display and the A to D off the sticks , together, because largely you might use one chip to do the lot.

as far as USB goes, its a very low level specification, and there us a lot more that you can do with it than run unidirectionally for a joystick or mouse or keyboard!


For example, I had occasion to get a 3G broadband dongle working: THAT was made to look exactly like an analogue modem. AT command set and all. so you could set up IP over PPP on it using a standard 'dialer'.

Should we make our RF modules look like modems, and run bidirectional IP/PPP over them to the receiver? And put USB sockets on them?

Probably not, because it means you need a PPP and IP stack on the receiver, which is a fair bit more computing power than you want to carry, BUT you might decide to use a modem like interface anyway. So AT commands could set up binding and the like.

I have tried to strip down receiver modularity so that teh receiver is small and cheap. In an ideal modular world, you might have an RF module with an interface to a decoder module, using e.g. USB like interface. That's what I described. In practice this is overkill, you want a single block that does RF to PPM servo outputs. It might be modularised coneceptually to allow different people to work on the different modules, but in practice the thing wouldn't be separable. Largely it seems that teh microprocessor that does the decoding also set up te RF chip into its correct mode, and accepts the data its sent as a serial data stream without much option to define and interface. Decoding to PPM is anyway not exactly hard.

What is more challenging is to design a receiver that responds to a single channel, twin channel or hopping transmitter..all set up at initial bind. And compatible with Futaba, Assan, spektrum etc etc.. I suspect this is ultimately not really possible, since these guys seem to use matched chipsets and proprietary modulations - the 2.4Ghz specs don't actually say that you have to stick to a protocol, only that you mustn't exceed a certain power spectrum.

[vintage1]

On frequency hopping.

If you define that you always cycle through *all* the channels, repeating the same frame till you get an ack, the receiver simply has to wait on a particular channel, until the transmitter comes around. At that point both 'know' where the next frame is going to be. Assuming the ack gets through from the receiver. If not both will hop to the next channel, and the same frame will get repeated. If the RX ack got through, it will be the next frame.

In the case of unidirectional ACKless hopping, again the receiver simply waits until the transmitter comes around, and probably expects to get a much larger frame with ALL the servo positions in it, so that as long as it finds enough channels free it will get a full update off any one of them..it will then hop to the next channel and wait..

In both cases you would want some sort of watchdog timer so that the receiver hops after an interval with no valid frame received, to avoid it getting stuck on bad channels. Or perhaps you might make it hop backwards in the absence of a good signal.

I think that trying to select which channels to use for hopping, is a pretty poor idea. Chances are that what the receiver is seeing as a bad channel at any given time is not what the transmitter might see. Use the lot, and if the receiver can synchronise with the hopping, great, if not, it can at least find a decent place to wait..

[Alan Hopper]

The tx/rx binding on my system achieves some of the 'are you the correct model' behaviour. The rx stores the mac address of the bound tx and the tx stores the rx mac address as part of the model description. Selecting the wrong model simply results in no response. For use in my son's toys I keep meaning to make a less severve option that auto detects the model on tx startup ie it finds the first model that responds or that sends out a beacon. This is obviously rf implementation specific but identifies to sort of cross cutting issues our ideal system has to cope with. The model definition part needs to know 'this is a model for the jennic rf link and this is the link specific data it needs to communicate with receiver x'. I guess binding info for known rxs could be stored in the rf module and the the model description could use a simple rx/link id. As receivers can move between models I had thought of making a simple model specific sensor that is permanently glued to the model and provides a unique id, this would have an extra use with my rxs as their outputs can be configured differently for different models.
Alan

[vintage1]

The tx/rx binding on my system achieves some of the 'are you the correct model' behaviour. The rx stores the mac address of the bound tx and the tx stores the rx mac address as part of the model description.



Atrer those gurabteed to be unique?


Selecting the wrong model simply results in no response. For use in my son's toys I keep meaning to make a less severe option that auto detects the model on tx startup ie it finds the first model that responds or that sends out a beacon. This is obviously rf implementation specific but identifies to sort of cross cutting issues our ideal system has to cope with. The model definition part needs to know 'this is a model for the jennic rf link and this is the link specific data it needs to communicate with receiver x'. I guess binding info for known rxs could be stored in the rf module and the the model description could use a simple rx/link id. As receivers can move between models I had thought of making a simple model specific sensor that is permanently glued to the model and provides a unique id, this would have an extra use with my rxs as their outputs can be configured differently for different models.
Alan

The way to handle this in the modularity model is to define a 'communicate only with this code' interface between the logic part of the transmitter and the RF module, and also 'find the nearest model(s) and return its(thir) MAC code(s)' command. Or some such. It's a bit like ARP (or is it RARP?) in Ethernet. Since where the model info is stored is indeed teh model meory, you need to store the codes there.

With that, you could switch the model on, and then the transmitter looks to see what MAC codes it finds that it knows, and asks you to select from a list, or automatically selects the one in memory that matches.

That, I assume, requires bidirectional comms to work though.

I see no reason however to not transmit in addition to a unique transmitter MAC code, a 'port' number relating to the actual model (memory?) in question. So that as you say, if you are on the wrong model, the model refuses to work.

Not a lot of use if you use one receiver in all your models mind you.

But the whole point is cheap receivers isn't it? :D

[Alan Hopper]

Obor,
my current (imperfect but working perfectly well) hopping scheme.

pretty much as Vintage describes

The rx and tx both know the mac address as a result of binding (another story).
From startup the tx hops every 20ms through all 16 channels, the order is randomized (once ) with the rx mac as the seed, this is to reduce the chance of two systems continuously interferring with each other. The sent packet contains the transmission time. Within this 20ms, packets could be sent 5 or 6 times if there is no ack.

At start up the rx hops every 16x20ms so if all channels are clear a packet should get through in the first 320ms. Once a packet has be received the clocks on the rx is syncronized to the tx and the rx starts hopping every 20ms

To cope with the rare possibility of the tx being reset in flight the actual sequence sent is a self resycronizing one, instead of sending 1 2 3 4 (shuffled) I send 1 2 3 4 3 2 1. This is not perfect as it relies on a particular channel to resync.

Vintage I agree about trying to pick good channels, it is also very easy to make matters worse by hopping on a non predefined sequence, however my next plan is to divide the 20 ms frame in half, for the second half I will use the above scheme but for the first half use a channel that only changes when it fails a few times.

Whilst reducing the number of channels used reduces the resync time you increase the risk of never syncing in very bad conditions.

I will try and remind my self the full details of my next plan :)

I consider it better to have fast resyncing on rx reset than tx reset as rx blackouts are far more common.

Alan

[Alan Hopper]

Vintage,
the mac addresses are issued from the great mac pool by jennic, they should be unique for all 802.15.4 devices (xbee jennic jeti xps ). It is possible to change/spoof them. Using the full mac address is optional when sending packets with these devices, I don't know if Xps or Jeti use them. Talking about Jeti and Xps and any other 805.15.4 based systems, these could all be made to talk to each other( and my system ), the manufactures just need their protcols banging together.
Does anyone know if any of the cheap systems are 802.15.4 based.
Alan

[obor]

Thanks Alan for your hoping scheme description.
One reason why I suggested to work on channel range is because the range can be computed, and reallocated whenever needed.
Imagine that there is a peak of activity on the 2.4Ghz middle range, occupying several channels let's say 10. If you have 20msec between channel switch, that means that 200 msec between real datas that can reach the receiver. The model will become "heavy" to control then.
Instead, at start or periodically (every 5 sec for instance), TX could check the most free channels available, and resend the new range to the receiver.
Another example: you fly with your lovely 4meter glider, and after take off, you decide to walk around the montain for fun. So, you will change location, and you may encounter a place where frequencies are more occupied, while flying your model. If the TX can dynamically rearrange the channels it uses, then you see the benefit.

Regarding the MAC address, it's probably not a good idea to use one from hardware because an OS protocol should not depend on a specific hardware type. Unique Id could be build on some hardware info (such as MAC address if exist) or other user information that may have been entered.

@vintage: comparison to tcp/ip model is strange to me, as RC control required much more real time data than TCP/IP. There is no need for Ack for instance, are new data are continuously pushed by the TX. And we have to better cope with off/on for quick restart.
Olivier

[Alan Hopper]

Obor,
I understand what you mean about there being a bad block of channels, my current system would suffer, however it responds instantly to changes in circumstances as it makes no decisions. I would prefer control every 200ms to a 1 second drop out when the selected block of channels go bad. My planned system improves on my current one by using the most recent best channel for the first half of the frame and if that fails the continuously hopping method for the second part, hopefully getting the best of both worlds. Whatever system you use you can always come up with a situation that is bad for it.
As I say it is good mental exercise, have fun.

As for using mac addresses, this is exactly the correct thing to use in a 802.15.4 radio link as that is what the hardware supports and uses to send messages to a specific receiver. Let the hardware do what it is good at. This is quite different to higher layers of protocol sent over the link or used to control it, these should use an addressing scheme abstracted from anything the hardware uses. I think it is hard to avoid some hardware specific data being stored with the model ie. the frequency for a synth tx is hardware specific just like my mac binding.

Alan

[obor]

Alan,
I agree with you, there will be always something which make the protocol not work. But it does not matter, as long as in the nominal case it addresses most needs, it's fine.

About the MAC address, I still think that an OS protocol should not depend on any hardware, and should be able to work with anything including old PPM systems.

[vintage1]

.

@vintage: comparison to tcp/ip model is strange to me, as RC control required much more real time data than TCP/IP. There is no need for Ack for instance, are new data are continuously pushed by the TX. And we have to better cope with off/on for quick restart.
Olivier

UDP/ IP requires no ack. What we are doing here is very similar to sending a datagram UDP packet (move servos to positions X) to a target address (unique model 'IP address' rather than MAC address).

IP protocol is very real time.

Conceptually I suppose a flying field is more akin to an ethernet cloud..many transmitters, many receivers and not a few collisions.

Anyway, I am used to thinking in network terms. Sorry :D

[gmb42]

I'll jump in here as this thread is very interesting as building my own 2.4GHz system using the Jennic modules found by Alan is very much on the cards after my summer holiday next week

My thoughts regarding the MAC address.

I like the block concept discussed earlier, and I see a Tx controller block which communicates with a RF link block.

The MAC address in 802.15.4 is a property of the RF link protocol, and conceptually the Tx Controller doesn't need to know what this is, it just stores the opaque blob given to it by the RF link in it's model memory.

For example, the Tx controller is put into "bind" mode. It issues an instruction to the RF link to bind. Automagically the RF link creates the binding between the Tx and Rx RF links. The RF link returns the binding info blob (possibly containing a MAC address, maybe something else) to the Tx controller which stores it in the memory for the model that is being bound.

Now next time we start up the Tx controller and select the model, it instructs the RF link to make a connection to the Rx passing in the binding info blob that the RF link understands and knows how to use.

Graham

[Alan Hopper]

Obor,
I utterly agree with you that our ideal system should work with anything. I suspect we are talking at cross purposes, what do you mean by 'OS protocol'. I am not suggesting that mac addresses are a primary part of any high level universal protocol, just that they are a reality of lower levels in some implementations. If we want to create a universal protocol, I believe it is vital that we don't restrict what goes on at the lower levels, if we do this, it only takes a new chipset or idea with some neat feature for our efforts to be wasted.

Graham,
I agree that model definitions need to be able to store some hardware specific blob.
I'm also on holiday next week but after that just shout if you get stuck( If anyone wants to sail at Ramsgate week I'm short of crew!).

Alan

[obor]

what do you mean by 'OS protocol'

I meant Open Source protocol.

UDP: yes why not. But maybe not for low bandwith systems, the headers add too much overhead.
And imagine also A DOS attack while you are flying ....:) .

Alan, have nice sailing next week, it looks to be a nice program.

[iter]

If anyone wants to sail at Ramsgate week I'm short of crew!Whatca sailing? I know you want to show us pictures!

Ari.

[iter]

as far as USB goes, its a very low level specification, and there us a lot more that you can do with it than run unidirectionally for a joystick or mouse or keyboard!


For example, I had occasion to get a 3G broadband dongle working: THAT was made to look exactly like an analogue modem. AT command set and all. so you could set up IP over PPP on it using a standard 'dialer'.

Should we make our RF modules look like modems, and run bidirectional IP/PPP over them to the receiver? And put USB sockets on them?The advantage of implementing an interface (an API, a line protocol, a physical connector) is that you can seamlessly connect to other components that already implement the other side of this interface. In the case of your 3G broadband device, dialers exist that know how to issue AT commands over a USB connection and so can seamlessly use your dongle.

I wonder what existing components can seamlessly use an RF module with a USB socket.

Ari.

[Alan Hopper]

Hi,
I've tried to sketch out a sort of protocol layer diagram

http://www.gliffy.com/pubdoc/1784726/L.jpg

It is basically a description of my current system, as such it is not a description of how I think things should be, just a starting point. I haven't drawn internal data flows and my black boxes are bigger than the systems talked about here.

Obor for an OS radio link I see that the bottom three layers on that link need defining. For a modular system it is the top two layers that are important for software compatibility and the bottom layer if you need to plug bits together.

There are probably further higher layers that could be defined.

Alan

[obor]

Hi,
This is a big picture :)
Starting with the TX to RX link.

routing layer: I don't see a need for "routing" as in network terms. May be I go wrong, but the most evident first need is a reliable and secure communication link between two (or more) end points (TX, RX) . You can't afford going through a third party that may be not reliable to carry information. And brings more complexity in a real time communication. In UDP world, as audio streaming, you can buffer. But not in RC.
So I see the routing as very straighforward.

Then comes addressing. Mac address or similar is fine, and Id as discussed earlier.

Then comes the addressing of servos behind the receiver. It's probably part of what is called "application data command layer".
TX does not need to be strictly awareof servos behind the receiver. It can provide logical functions which are translated by the receiver. Logical function can have a straight forward mapping to channel in the case the receiver has no intelligence (almost all receivers currently on the market).

What else is needed ? packet signature ?
Olivier

[Alan Hopper]

Olivier,
I'm talking about a lightweight routing protcol with minimal overhead (no dns lookup :) ). I see a need for it eg I might have your tx connected to my tx module connected to my rx with a secondary rx with gps connected to the sensor bus. I want to plug a pc into your tx and get logs from the secondary rx. I don't think your tx should need to know specifics about this, it just needs to pass message to and from the pc and rf module with enough info for them to route them on. To do this I think there has to be routing, I see this routing layer as separate from lower level adressing schemes such as mac. For the basic tx-rx messages this routing is obviously of less value (but great for debugging). It also gives you features such as contol of servos from pc for no effort, the same messages are just routed from further up the chain.

I do see the "application data command layer" as where servo commands are defined, this is probably a good command to try and define first as it is the primary function of our systems, I'm sure we will be able to discuss data types, number of channels etc for some time :)

Whilst commercial receivers are generally pretty dumb, many of the projects on this site involve a lot of onboard intelligence eg. uavs,multicopters etc I think the ideal system should allow for these systems.
Alan